@RockyHawk --

You can, and I also want to strongly emphasize this works best for setup or a one-time loader function: do not call loadImage() in draw(). Most of the the time this is a mistake -- and a terrible performance hit.

Calling loadImage every time an image is needed in a running sketch is solving "how do I choose between different cereals for breakfast?" is "order a new cereal box from Amazon every time you feel hungry, then sit and wait until it arrives." It works, but now you sitting at the breakfast table for two days waiting for your cereal -- and you only eat breakfast every two days.

@jeffmarc Great you cross-linked to the previous post. I will strongly suggest you continue any other discussions here.

Related to your code. Are you calling loadImage() in draw()? Additionally, are you using the standard or P3D renderer?

To check what loadImage() does, visit: https://github.com/processing/processing/blob/master/core/src/processing/core/PApplet.java#L5370

If you are working with a png type of file, go to: https://github.com/processing/processing/blob/master/core/src/processing/core/PApplet.java#L5425

I really don't understand Java and Processing then, in C,C++ there is code that defines functions like loadImage and they behave a certain way all the time so you can determine how to use them or program a work around.

If you come from C/C++ background, then it might work as you said. If you are using a library or framework, you can only guess what they do unless you check under the hood. If the library is widely used, either other people could have found a problem, it gets reported and it is solved.

Processing is not any different. The loadImage is performant. When a bug is found, well it is bad and it is good. Bad because it affects your code. Good bc you found it and you could report it. However...

When you find a bug, the first instance you should take is: Is it really a bug or is it something else.... like "me". In other words, for a something that smells like a bug and walks like a bug, it needs to be a bug. But you need to prove first it is a bug. There are two ways:

1. You go into the source code, you trace the code and you show the problem. You can go the extra mile and propose a solution. You can fork the repo and re-generated the jar files for a modified version of Processing where you fixed the bug. This way you demonstrate not only that the bug is real but you also have a solution. Notice a solution is not the solution unless it doesn't break any other features in Processing. Otherwise a more careful solution is required.
2. Another way is to provide a sample code and then other community members can run the sample code and confirm the bug. You see, this approach is more convenient for the layman because the work to be done is minimal. The community validates the problem and then you can proceed to open a ticket in github. This step is also convenient because it also shows your approach, or maybe there is a better way to do the things you want to do.

Related to loadImage() using the same memory space. Not sure if that is true. I hope Java is smart enough to do that. The JVM suppose to be able to optimized your code after it is run few times. I cannot say much about code optimization as it is out of my realm. However, you need to remember there is an extra layer between your code and the JVM and that is the Processing layer. At this point one can assume Processing is doing the right thing unless proven otherwise.

Once again, an MCVE is needed. If you open a ticket in github related to this issue, the first thing they will ask if for some code demonstrating the problem. People can tell you so many times what is needed here but if you don't collaborate, everybody's efforts are just and simply wasted. So before you claim something and based this problem on an assumption from your side, show some code.

Kf

Continued: https://forum.processing.org/two/discussion/27810/out-of-memory-error-on-loadimage-in-draw-loop

So the Java garbage collection and memory management works in the background . In post from 2016 from Henri , "PImage won't release memopry" KevinWorkman says the Java garbage collection and memory management works in the background so "Out of Memory" error should never happen. Wonder if it is fixed in later versions or what cause I get it in the following scenerio.

Using 2.2.1 and getting out of memory when i run sketch. basically it asks the user to grab an image. The image is then loaded with loadImage() After 1000's of draw loops , i get out of memory and sketch halts with error messages in console. Is the auto memory management in Java the same in this version or better in later versions of Processing? The program uses an event counter to allow only one iteration of each condition in the draw loop. 

  Step 1 - wait for user to request image grab 
  Step 2 - loadImage and display with image() 
  Step 3- perform image processing 
  Step 4- report numeric results ( count all pixels below threshold) 
  Reset event counter to 1

  I inserted a wait time of 1 second to auto initiate the loop and it runs for hours and finally gives out of memory 
 So is the garbage collector not working in theis version or what?

Thanks

I bet money that he's calling loadImage in draw, every frame, and that's the problem. It just needs some logic in there to use the current image until the new one is available.

Post some code.

Not possible for my application. I create PImage img in setup. But my draw loop calls a outside utility to grab new image to a .png file. Then I load the img with loadImage() in draw loop and display. Is there something I can do to insure loadImage does not leave memory behind when called multiple times ?

In general, if at all possible, don't use loadImage() in draw. Use it in setup().

1. In setup(), load your images once into img / img2 / img3 or into PImage[] images.
2. in draw() reference them as many times as you like in your draw loop -- referencing them will not allocate new memory, because you aren't uselessly creating and destroying objects for the same smthimg.png many times per second.

don't loadImage in draw() or anywhere called from draw(). do it in setup().

but first, format your code.

In general: Do not use loadImage() in draw().

Constantly reloading image files at 60fps is a huge performance issue in any version of Processing (or really any language).

Use loadImage() in setup, or for spaced out events when you cannot preload.

• https://forum.processing.org/two/search?Search="loadimage+in+draw"

• https://www.google.com/search?q=processing+"loadImage+in+draw"

You used loadImage() in draw (lines 78, 89, 93 and so on). You should avoid this at all cost. Instead you can move these lines to setup() like you did at line 39.

@Bhargav I think you may not be understanding the key issue here.

By putting loadImage in draw you are loading the same image over and over 60 times a second and 60 new times the next second and then 60 times again, and again, and again, and again. Unless you are changing which image you load 60 times a second, this is... not smart.

• You want to load a new image each time the mouse is clicked? Load each new image with mouseClicked().
• You want to load a new image each second? Create a separate function that is called once a second to load new images.
• You want to load an image each time the use presses a key? Load new image with keyPressed().
• etc. etc.

This has nothing to do with you using a lot of images or loading often. Even a program that loads 100 new images each second should not put loadImage in draw. If it did, it would load images 0-99 from the hard disk, then load those same images 59 more times in a row for no reason -- then on the next second it would load images 100-199 from the hard disk, then it would reload those identical images again 59 more times in a row for no reason, etc.

@TajA, to clarify, running "loadImage" in draw() will attempt to open your image file and load the data 60 times per second. If the image takes longer than 1/60th of a second to load, hilarity ensues -- if you want to build a house and then go inside every day, don't start building a house every day, then demolish what you've built every midnight and start over. Just build it once. Then go inside every day.

From the loadImage() reference:

In most cases, load all images in setup() to preload them at the start of the program. Loading images inside draw() will reduce the speed of a program. Images cannot be loaded outside setup() unless they're inside a function that's called after setup() has already run.

Is Fond the background image?

First of all don't call loadImage() in draw()! It will load the image from your disc on every draw iteration, slowing down your sketch, but you only need to do it once. Place line 19 in setup(). The same applies for line 9 in the joueur class, here the vitesse() method can be seen as the draw() method of the player. The best thing you can do is create a constructor for the joueur class and do loadImage() there:

class joueur {

  int compteur=0;  //déclaration de la vitesse initiale du joueur
  float vitesse;

  PImage Fond;

  joueur()    //constructor
  {
    Fond=loadImage("Moto.png");
  }


  void vitesse() {



    image(Fond, 300, 435, width/16, height/8);


    if (keyPressed==true && keyCode==UP) {
      compteur=compteur+1;
    } else {
      compteur=0;
    }
    if (compteur==1) {
      vitesse=vitesse+1;
    }
    println(vitesse);
  }
}

The joueur() method is the constructor of the joueur class as they have the same name. It is automatically called when you do Joueur = new joueur(); in your setup.

Now for your actual question, I don't quite understand what you mean. What Y position? Do you want to repeat the background image?

use ctrl-t in the processing editor to indent code properly.

int d=0;
int k=0;
int b=0;
int k2=0;
int d1=0;
int d2=0;

use meaningful variable names.

int[] b = new int[height];

be careful not to obscure said meaninglessly named variables with others of different type in narrower scope.

don't call loadImage in draw()

FORMAT YOUR CODE.

No.

NO.

NO!!! NO!!!!! NO!!!!!!!

NOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!

X(

DO NOT USE loadImage() IN draw()!

Every time you call loadImage() in draw(), you cause the souls of a thousand dead programmers to scream out in agony.

1) Do your loadImage()ing ONCE, inside setup().

2) The function for doing text is text():

PImage img;
int count = 0;

void setup(){
  size(400,400);
  textAlign(CENTER,CENTER);
  fill(255);
  // img = loadImage(""); // Yes. Here. Yes.
}


void draw(){
  //img = loadImage(""); // NO! NOT HERE.
  // THIS IS VERY BAD.
  // THIS IS SO BAD THAT IF YOU DON'T FIX IT RIGHT AWAY I WILL RIP A PHONE BOOK IN HALF IN A FIT OF TOTAL RAGE.
  // I LITERALLY CANNOT EXPRESS HOW WRONG IT IS TO CALL IT HERE.
  background(0); // img);
  text("You have clicked " + count + " times.", width/2, height/2);
}

void mousePressed(){
  count++;
}

In the other trhead I posted a version that don't use loadImage in draw...

rule #1 in processing - don't loadImage() in draw(), use global variables and do it in setup(). it will be 100s of times faster.

yes, as chrisir said, you need to redraw the static parts of the image as well as the moving parts.

when you want to have different images at the same position you could make an array of images

randomly you set the index for the list and display the current image

(Pseudo Code, not tested)

before setup()

PImage[] images = new PImage[22];

in setup():

images [0] = loadImage....
images [1] = loadImage....

in draw() or so

int index = int(random(22));
image ( images[index], x,y); 

A number of remarks:

• Choose a category when posting.
• Don't use all uppercase in subjects. (Fixed)
• Don't call size() twice.
• Avoid calling loadImage() in draw() (unless you control when you do that). That's a slow operation, and it is done 60 times per second... Probably applies to alphaRect() call as well. Since the image doesn't change and there aren't so many, just load all your images in setup().

Back to your problem: do you have any other error message? Can you read the video in a simpler sketch, like the ones given as examples in Processing? Some video formats are not supported by the video library.